Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@magicblock-api/src/magic_validator.rs`:
- Around line 115-120: Wrap the await on self.0.schedule_undelegation(pubkey,
request.account).await in a tokio timeout (e.g.,
tokio::time::timeout(Duration::from_secs(...), ...)) so the call cannot hang
indefinitely; after awaiting the timeout, map a timeout error to the same
chainlink/committor error variant currently produced (the "committor response
channel closed" mapping) so both channel-closure and timeout produce the same
error path, and then continue to .and_then(|result| ...) as before; update
imports if necessary to include tokio::time::timeout and Duration and ensure the
timeout mapping converts into a String consistent with the existing
.map_err(|message| ...) flow.

In `@magicblock-chainlink/src/chainlink/fetch_cloner/tests.rs`:
- Around line 251-255: The mock server's blocking accept loop inside the
tokio::task::spawn_blocking worker (which calls listener.accept() in a for
0..expected_calls loop) can hang CI if fewer connections arrive; modify the
worker to enforce a hard timeout (e.g., 5s) for each accept or for the entire
loop: set the TcpListener to non-blocking (listener.set_nonblocking(true)) or
use Instant::now()/elapsed to track time, repeatedly try accept() with a short
sleep, and if the deadline is exceeded before receiving all expected_calls,
break and return an error (or panic) so the test fails fast instead of hanging
while the test awaits the worker join. Ensure the change is applied to the same
worker block that spawns the mock server and to the other similar instance
mentioned (around the other accept loop).

In `@magicblock-chainlink/tests/10_aml_undelegation.rs`:
- Around line 70-74: The mock risk-server worker can block forever on
listener.accept() inside the spawned closure (the worker) causing join() to
hang; change the worker loop to avoid blocking by calling
listener.set_nonblocking(true) (or use try_accept if available) and perform a
bounded retry loop with a short sleep, counting successful accepts until
expected_calls or until a configurable timeout elapses, then break and return an
error/result so the task completes; update the code that awaits the worker (the
join() site) to handle the early-return error case. Ensure you reference the
spawned closure (worker), listener.accept, expected_calls and the join()
awaiting the worker when making the change.

In `@magicblock-committor-service/src/committor_processor.rs`:
- Around line 302-309: The current intent_id() uses wall-clock nanoseconds which
can collide; replace it with a collision-free generator such as a monotonic
atomic counter or a UUID-based ID instead of SystemTime::now(). Specifically,
update the intent_id() function to read from a shared AtomicU64 (e.g.,
NEXT_INTENT_ID.fetch_add(1, Ordering::SeqCst)) or generate a UUID and
convert/encode it for ScheduledIntentBundle.id so each undelegation gets a
unique, monotonic or globally-unique ID; ensure the chosen generator is
initialized and accessible where intent_id() is called and that persisted
keys/status lookups use the same ID format.

In `@magicblock-committor-service/src/service.rs`:
- Around line 68-72: The ScheduleUndelegation variant embeds AccountSharedData
which causes CommittorService::try_send() to log full account bytes on
TrySendError::{Full,Closed}; change the logging to avoid dumping the account
payload by either redacting ScheduleUndelegation's Debug output or logging only
the pubkey and message type. Concretely, update the CommittorService::try_send()
error paths that currently log the CommittorMessage to instead pattern-match the
message and log a concise string for ScheduleUndelegation (e.g.,
"ScheduleUndelegation { pubkey: <pubkey> }") or implement a custom Debug/Display
for that enum variant that omits AccountSharedData; ensure references to
ScheduleUndelegation, CommittorMessage, AccountSharedData, Pubkey, and
TrySendError::Full/Closed are used to locate and change the relevant code.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test-integration/Makefile`:
- Around line 57-64: The test-aml target bypasses required program preparation
because the shared test target only runs chainlink-prep-programs when RUN_TESTS
is empty or contains chainlink or cloning. Since aml.devnet.toml requires
artifacts from ../target/deploy/miniv3/program_mini.so, ensure
chainlink-prep-programs is invoked before running aml tests. Either add aml to
the condition that triggers chainlink-prep-programs in the shared test target,
or explicitly invoke chainlink-prep-programs as a prerequisite step in the
test-aml target (similarly to how other test configurations handle program
preparation).

---

Outside diff comments:
In `@programs/magicblock/src/utils/instruction_utils.rs`:
- Around line 82-84: The for loop in instruction_utils.rs that processes PDAs
(line 82-84) marks each account as both writable and signer using
AccountMeta::new with true as the second parameter. However, according to the
instruction specification in magicblock-magic-program-api/src/instruction.rs at
line 57, accounts 2..n should be read-only, non-signers. Change the
AccountMeta::new call to use an appropriate constructor method that marks these
PDA accounts as read-only and non-signers instead, since only the payer is
expected to sign the transaction and marking non-payer accounts as signers will
cause transaction sanitization to fail in production.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@magicblock-account-cloner/src/lib.rs`:
- Around line 873-878: The panic messages in the match arms for
PostDelegationActionExecutorInstruction::ScheduleUndelegation are inverted and
misleading. These arms trigger when ScheduleUndelegation is unexpectedly
received, but the panic message says "expected schedule undelegation
instruction" which is backwards. Locate both occurrences of the
ScheduleUndelegation match arm and update each panic message to accurately
reflect that ScheduleUndelegation was received unexpectedly, and state what
instruction was actually expected instead (which should be Execute based on the
test expectations).